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PROGRAM CONTROL AS A SET-THEORETIC CONCEPT 



by J. R. Jefferson Wadkins 

A point does not move, a circle does not shrink, a number does not change its value, and a 
function does not decrease. Each of these mathematical entities is a set; it is static; it takes no action; it 
does not change; it just sits there being a set. Nevertheless, the notion of variable mathematical entities 
is present in most mathematical activities and permeates the teaching of mathematics. 

Thus teachers feel no shame in saying things like "as the point (r t A) moves from right to left on 
this curve, the circle with radius r shrinks...", because they are justifiably confident that the language they 
use, which employs the notion of variable mathematical entities, can be converted to the static language 
of set theory in the context of axioms for a complete ordered field. While there are purists who frown 
upon use of "variables" in serious mathematical discourse, most mathematicians are comfortable with 
such phraseology because of the existence of precise semantics that legitimize these notions in terms of 
set-theoretic concepts from which the purist might prefer never to emerge. 

1.0 PURPOSE AND MOTIVATION FOR THIS PAPER 

Precise proofs of program correctness and precise proo£s in calculus are arguments about static 
entities. Both are typically introduced with teacher as actor and students as spectators, but there is an 
implicit understanding that students are only being "exposed" to these techniques. The answer to the 
ever-present, student-as-spectator question, "Are we responsible for this on the next test?" is almost 
always negative in both cases. However, there is a vast difference in how introductory courses handle 
intuitive notions consistent with corresponding precise ideas. 

In typical beginning calculus courses, the notion of "variable" is employed to give plausibility 
arguments for fundamental theorems that are seldom stated in such courses very precisely, and seldom 
justified with epsilon-delta arguments; but students do gain an appreciation of the fundamental nature of 
such theorems by constantly taking part in both home-work exercises and classroom activities that 
employ "variables" to reason about specific applications of those fundamental theorems. Although there 
is a programming notion used in introductory courses for other purposes that could be used to give con- 
vincing arguments for both fundamental theorems of program correctness and instances of their 
application to code written by beginning programmers, use of this intuitive notion in teacher presen- 
tations which give plausibility arguments that code segments satisfy their informal specifications would 
seem to be relatively rare. 

That programming notion is "program control", an entity used by both neophytes and 
professional programmers for "desk checking" of code before testing it. The readiness of mathematics 
teachers to use hand-waving arguments in calculus presentation-, as opposed to the hesitancy of 
computer science teachers to use the notion of "program control" in their classroom presentations, is 
probably best explained by the fact that "real variables" have a widely understood logical basis, while 
"program control" is ofrm thought to be a mere heuristic, unrelated (indeed, contrary to) precise proofs 
of correctness about static entities employing the weakest-precondition predicate transformer. 

Use of "program control" provides a short and simple argument for a fundamental theorem of 
program correctness*, which Edsger Dijkstra stated without proof in his seminal 1975 paper [1] and 
whose proof, using the symbolism and tools of the formal predicate calculus, is outlined (as the answer 
to three exercises) taking up more than two pages of densely packed symbolism in The Science of Prog- 
ramming by David Giles [2]. 

The purpose of this paper is to provide operational semantics for imperative programming 
languages that legitimize the phraseology used in the statement and proof of our version of that fun- 
damental theorem. We would venture to claim that both the statement and proof of our version of this 
theorem (as given in the next section) can be made understandable by, and convincing to, typical 
beginning students who have no preparation other than what is typically offered in the first half of CS1 
- and that this can be accomplished with very little effort on the part of the teacher. This is clearly not 
the case with even the statement of the theorem in the development of either Dijkstra [1] or Gries [2]. 



* That argument and that theorem is given at the beginning of Section 1.1. 



Motivation for the research that culminated in this paper was two-fold. The first was a question 
posed to this writer by a high school teacher in 1988.[4] The second was a number of rewrites by David 
Gries of arguments offered by this writer during collaboration on a paper [3] in 1989-90. The question 
from the teacher, Alexander Z. Warren, arose when he and two other high school teachers of computer 
science were asked to review an earlier paper on loop invariants by this writer. (Tht collaboration on 
[3] was kindled by Gries' review of the earlier paper.) The earlier paper was intended to convince those 
high school teachers of computer science who were also teachers of mathematics that the mysterious 
concept of a loop invariant could be easily comprehended if they considered it merely the induction 
hypothesis for an induction proof that the loop accomplishes what the programmer intended. Warren's 
otherwise positive reaction to the paper was tempered by worries about an argument in that paper 
referring to program control. Those worries are best summarized by the question, "What are the 
axioms?" Additionally, the rewrites by Gries during collaboration on [3] always resulted in exclusion of 
any reference to program control. Those repeated exclusions coming after Warren's tantalizing question 
led to this writer's determination to validly give the answer, "The same as those for set theory." Our 
paper here does provide the validity for that answer. 

1.1 A FUNDAMENTAL THEOREM OF PROGRAM CORRECTNESS 

Several phrases used in the following theorem and its proof are normally undefined, but intui- 
tively appealing. We here contend that programming students would not question the validity of their 
use any more than mathematics students question the normally undefined, but intuitively appealing, 
phraseology of "variables". The purpose of this paper is to give precise meaning to the questionable 
phrases used in this section. 

1.1.1 Theorem : In some program containing no goto's, let Expr denote an expression that is a function 
of the program variables, let c be a number, let Pcv and Inv be statements about current values 
of program variables, and let W denote the following loop. 

while < guard > do 
begin 

2: 

<body> 

3: 

end 

(1) A sufficient condition that W terminate is that, during any execution of W y 
both <guard> and <body> terminate, 

no program variable changes value as a result of any evaluation of <guard>, 
the statement n Expr < c" is true each time program control reaches < guard >, 
and 

whenever program control reaches line 2, if v 0 denotes the value of Expr at that 
time, then the value of Expr is at least v 0 +l the next time program control 
reaches line 3. 

A sufficient condition that Post be true whenever program control reaches line 4 is that 
(v) (Inv and not < guard >) implies Post 



(i) 
(ii) 
(iii) 

(iv) 



(vi) Inv is true each time program control reaches <guard>. and 

(vii) during any execution of W that terminates, no program variable changes value as 
a result of any evaluation of <guard>. 

Proof of (1): Let E be any execution of W, and assume (i), (ii), (iii), and (iv). By (i), program control 
must reach line 3 subsequent to any time during E that it reaches line 2; and, by (iv), the value 
of Expr must increase by at least 1 each time <body> is executed. Expr has some value v 0 the 



first time program control reaches <guard> during E. By (iii), "v 0 < c" is true at that time. 
There are only finitely many adjacent intervals of unit length beginning at v 0 and ending at a 
number that is at most c, so <body> can only be executed finitely many times during E 
(perhaps zero times) -- for, otherwise, because of (ii) and (iv), the value of Expr would have to 
increase beyond c during some execution of <body>, rendering assumption (iii) false. Thus, it 
must also be true that < guard > can only be executed finitely many times; so E must terminate, 
which completes the proof that W terminates. 

Proof of (2): Let £ be any execution of W that terminates, and assume (v), (vi) and (vii). We must 
show that Post is true when program control reaches line 4 at the end of E. Because of 
termination, there is a last time t that program control reaches <guard>, and since Inv is true 
each time program control reaches <guard>, Inv is true at time t. Also "not <guard>" is true 
at time t -- because, otherwise, t would not be the last time program control would reach 
<guard>. Thus by (v), Post is true at time t. By (vii), no program variable can change value 
during the execution of < guard >, so since Post is a statement about current values of the 
program variables, Post must still be true when program control leaves < guard > the last time 
during E and then reaches line 4 as £ terminates, q.e.d. 

Note on a theorem parallel to Theorem 1.1.1 : It should be clear that the argument indicated above is 

easily adjusted to form the proof of the parallel theorem obtained by substituting ">" for "<" and 
substituting "at most v 0 -l" for "at least v 0 +l" in (iii) and (iv), respectively, of part (1) of 
Theorem 1.1.1. This substitution comes close to Dijkstra's use of "variant function", which Ones 
calls a "bound function". However, there is a difference: for our theorem, "c - Expr > 0" is an 
invariant, whereas in the Dijkstra-Gries approach, the bound function (which corresponds to our 
"c - Expr") is only required to be nonnegative up until the final evaluation of the guard; upon 
termination, the variant function (bound function) is allowed to have a negative value. Finally, a 
variant function (bound function) is required to be integer-valued, whereas c - Expr has no such 
restriction. 

Note on the proof of (1) : It should be clear that the proof of (1) goes through if any arbitrary positive 
number d were substituted for the increment 1 in the "v 0 +l" of (iv) in the statement of Theorem 
1.1.1, and in the "v 0 -l" of the "parallel theorem" just discussed. (The real numbers form an 
Archimedean field.) However, the only practical effect of such a substitution known to this 
writer is in using the invariant inequality "Expr > 0", where Expr = lo&Cfc+l), in the proof of 
termination for any loop that uses "k := k div 2" to make progress toward termination -- in 
which case the decrement to k from 2 to 1 res: 'ts in only a decrement to Expr of log 2 3 - log 2 2, 
which equals log 2 (3/2) < 1. Termination can be proved in such a case using either k (if proof 
of termination is the only goal) or flo&CJfc+l)] (if an expression that counts iterations of the 
loop is desired). Thus, there seems no good reason to complicate matters in the statement of a 
theorem claimed to be understandable to the most novice of programmers. 

For writing code, the real value of Theorem 1.1.1 lies in the following corollary, which provides 
a programming template for the construction of a loop with a built-in proof of its correctness just by 
writing two segments of straight-line code to fit given specifications, i.e., without having to visualize a 
repetitive process. 

1.1.2 Corollary : Using the notation of Theorem 1.1.1: In order to write correct code for a loop 
intended to establish assertion Post, it is sufficient that 

(1) a Boolean program expression, <guard>, and a statement Inv about the program variables be 
chosen such that <guard> terminate; and has no side effects, and such that the implication 
"(Inv and not <guard>) implies Post" is true, 

(2) code be written as an initialization that terminates and makes Inv true in line 1, 
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(3) a number c and an expression Expr be chosen such that 

(i) "(<guard> and Expr < c) implies £xpr+l < c" and 

(ii) the already-written initialization also makes "Expr < c n true in line 1, and 

(4) code for <body> be written that 

(iii) terminates and contains no goto, 

(iv) increases the value of Expr by at least 1, and 

(v) has the property that if "<guard> and Inv and Expr < c" is true when program control 
reaches line 2 during any execution of W y then "Inv and Expr < c" must be true the next 
time program control reaches line 3. 

This Corollary follows from Theorem 1.1.1 and its argument is in the same spirit as the 
argument for the Theorem, and it is omitted. 

While the purist might argue that the wording of the Corollary encourages operational thinking 
in the process of creating a loop, as opposed to the static reasoning used in the predicate- transforma- 
tion approach, such operational thinking is restricted to two segments of straight-line code (the 
initialization and the body), a restriction that would certainly move the student in the direction of static 
reasoning and away from the total dependence on the vision of repetitive processes that usually permeate 
the teaching of loop creation in introductory courses. 

2.0 THE OPER/ TIONAL SEMANTICS 

Section 1 presented the fundamental theorem and its proof using terminology that might be 
considered plausible but not rigorous, intuitive but not precise. This Section 2 provides precise 
operational semantics for imperative programming language systems in terms of set theory. Section 3 
provides the translation of the words and phrases of the fundamental theorem and its p:^of in Section 1 
into the precise set-theoretic terns of Section 2, thereby refuting the natural conjecture that the theorem 
and its proof is "plausible but not rigorous, intuitive but not precise". 

The only prerequisite for understanding the technical development of the operational semantics 
here is a high level of mathematical maturity. Although the mathematics is elementary, the extensive 
mathematical shorthand that is employed presents an intimidating facade that might be expected to 
prevent any but the most interested reader to gloss over the details of the proofs and definitions. 

In mathematics we often have two choices for development of a system: 1) choosing axioms and 
definitions that state many of the properties objects satisfying those premises should have, but some- 
times the price paid is an inordinate complexity in the proof of some fundamental theorems based on 
those premises; 2) choosing premises requiring more complexity in early development, but the reward is 
sometimes to make the proof of some fundamental theorems simpler. 

To begin: "Txe approach taken by Dijkstra in [1] using the weakest-precondition predicate 
transformer makes definition of his guarded-command language very straight-forward, without need for 
any concept of execution. A comparison of the proof of his fundamental theorem (as given in Gries [2]) 
with our proof of the corresponding Theorem (our Theorem 1.1.1), or with the reader's own plausibility 
argument for our version, shows the price paid for the simplicity of his early development. The price we 
pay here for a simple proof of this fundamental theorem is a heavy layer of complexity in the develop- 
ment of operational semantics from the axioms of set theory. 

2.1 PREVIEW OF THE SEMANTICS 

Many phrases appearing in Theorem 1.1.1 need precise definition, but the offending phrase that 
is most fundamental is "program control". In our development, "control" is a function taking ordered 
triples (S,s,p) into other such triples, where 5 is a string of "tokens", s is a "state", and p is a "position". 
A state is a function from the nonnegative integers (intuitively, the addresses in the memory of an ideal 
machine) into a set of "values" stored in ROM, with each "program" having some final segment of 
addresses available beyond ROM; a program is a finite sequence of tokens; and a position in the 
program is one of its subscripts. 

For the stated purpose of this paper, the only programming construct needing definition is a 
loop. However, in our development, the syntactical form of a loop is the same as that of a simple 
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conditional; and until we specify how such a construct is executed, there is no way to tell which is which. 
An execution is a sequence of ordered pairs in the domain of "program control", which is a function, 
derived from the system-defined function called "control", that maps pairs (*,/>) of states and positions 
into other such pairs. The position of the first term in the execution of a program is the position of the 
first token of the program. It is a theorem that, for any state s and any program P, there exists a 
unique execution of P with (s, 1) as its first term; and, in general, if there exists any execution of 
program segment S with (s, min. Domain. S) as its first term, then that execution is unique. 

Our use here of "Domain. S " indicates that we consider 5 to be a function, and we do indeed 
make strong use of the viewpoint that a sequence is a function whose domain is a segment of the 
integers and that a function is a set of ordered pairs no two of which have the same first element. 
While there are other legitimate points of view, the basis for the semantics to be given here is set 
theory, so every object used in the development is defined to be a set/ 

For this development, we must distinguish between strings and sequences. Execution is only de- 
fined for program segments, which are sequences whose domains can differ, depending on their positions 
in parent programs. Yet a programming construct should be defined without reference to where it 
appears in a program, and should be distinguishable from its particular appearance in a program. The 
mechanism we use for this purpose is to define a string as an equivalence class of finite sequences with 
each member of a given class having the same length and the same terms in the same order. In this 
way, given a programming construct as a string, each appearance of that construct as a program segment 
(a sequence) is a member of the equivalence class that is the string. Conversely, given a subsegment of 
a program, there is a unique equivalence class, i.e., string, containing that subsegment as a member. 

2.2 BACKGROUND NOTATION, CONVENTIONS, AND POINT OF VIEW 

Because the view of a function as a set is so fundamental to our development, we state again for 
emphasis the characterization of functions already indicated. 

2.2.1 Note : A relation is a set of ordered pairs. A function is a set of ordered pairs no two of 

which have the same first element. 

We assume as familiar the usual notation for sets. As logical shorthand: "3 - 3 n denotes "there 
exist(s) - such that"; "V" denotes "for each"; and "a" denotes "and". We use two kinds of definitions. 
One we call "Definition", wherein we define the meaning of a statement in terms of statements already 
defined. The other we call "Notation", which provides a new name to a set that is already defined. In 
"Definition", we use "-" as shorthand for "denotes" whenever later reference is needed for a long expres- 
sion. In "Notation", we also use whenever new symbolism is defined in terms of already-defined 
symbolism; and there we sometimes use the concept of a "class" for aggregates that are in a sense too 
large to be sets. This is for notational convenience; we perform no operations on such classes; so we 
need not worry about binging down on our development the wr \th of such things as Russell's Paradox. 
Finally, we employ the label "Observation" for theorems whose proof either follows directly from 
immediately preceding definitions or is a completely standard and well known exercise in mathematics. 
Each observation that we make facilitates understanding of a later definition, theorem, or proof. 

2.2.2 Notation : n Sef denotes the class of all sets. 

"Relaf denotes the class of all relations. 

V S e Set, n #S 0 denotes the cardinality of 5. 

V r e Relat, n Dom. r " and "Rng. r n denote the domain and range, respectively, of r. 
Z s { n | n is an integer} a Z + * {n e Z \ n > 0}. 

V m e Z, V n e ZuM, if n e Z then Z m n *{keZ \ m < k < n) a m..n m Z m n 

a if n = « then Z m n ■ {k e Z | m < k} a Z m + * Z m * 



" Actually, for convenient notational purposes, we shall recognize "classes* too large to be sets, but 
these could be eliminated from the development without loss of accuracy. 



2.23 Observation : Z + = Z* A V m,n € Z, Z m n = m..*. 



2.2.4 Convention : VJteZ, = «-ffc ~ *>-k - &> > k. 

Although the following notation is fairly standard, it seems appropriate to slate it specifically. 

2.2.5 Notation : VSJe Set, "/: S -T" is a statement and 

/: s — T *=> (f is a function a Dow./ ~ S a /tog. / c 3T) 
A7 5 «{/|/:5-r} 
a 2 5 * {reSer | 7 c 5}. 
V n g Z, V 5 e Ser , 

if 5 Q Z n + a 5 * 0 then "win. 5 " denotes the minimum of S 

a if #5 e Z + then "wax. 5 " denotes the maximum of S. 

2.3 SEQUENCES AND STRINGS 

As already indicated, the view of a sequence as a function is not just a matter of taste; it is 
fundamental to our development. In the following definition, we restrict the meaning of "an infinite 
sequence" to mean "an infinite sequence with domain the nonnegative integers". These are the only kind 
of infinite sequences that we need in this paper. By restricting the meaning to the subject matter at 
hand, we can offer succinct comments to the reader, which are also technically true, but which would be 
technically false in more general contexts. On the other hand, the following definition also expands the 
meaning of "a finite sequence" to include functions whose domains are arbitrary segments of the integers 

not just the nonnegative integers. This expansion of the usual meaning of "a finite sequence" allows 
us to haadle in the general case what would otherwise be special cases. 

2.3.1 Definition : (sequences) 

s is an infinite sequence «=> (3 A e Set B s : Z 0 + — A) 

s is a finite sequence <=> (3 m, n e Z 0 + A 3 A e Set b s : m.. n — A) 

2.3.2 Notation : V A e Set y 

Seq.A - { s \ s: Z 0 + -^4} 
a Fsq.A ^ { s | s is a finite sequence a Rng.s c A} 
A V s e Fsq.A, 

SEG. s m { t I 0 7* t Q s A V k € Z, V ij € Dom. r, if i < k < j then k g Dom. t} 

For general functions, we often use "/. c" to denote the standard "/(c)" in order to minimize 
nested parentheses, employing parentheses only for functions with more than one argument or to avoid 
ambiguity. We generally use "/" whenever / is a sequence. (If / is a tuple, we also use f c to denote the 
component of/.) 



2.3.3. Definition : (equivalent sequences) 
s is yl-equivalent to t <=j 



A G Set A s y t G Fsq.A 
'a #s = #r 

1A V I 6 0..#5-l, 5min.Dom.j+i = ^min. Dom. u 



2.3.4 Observation : V A e Set, "is ,4-equivalent to" is an equivalence relation on Ft /.A. 
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23.5 D efinition : (strings) 



Str is an ,4-string 



A s Set A Str Q Fsq. A 
a V s,t G Fsq.A, 
(s,t e Str «=> s is ^-equivalent to r) 



As previously indicated, program constructs will be defined as strings of tokens. These 
constructs are most easily remembered an1 recognized as the concatenation of singleton strings whose 
defining token is a mnemonic identifier. The notation «s*T n is used for the concatenation of strings 5 
and 7, and is precisely defined as follows. 

2.3.6 Notation : V A e Set, STR. A « { x | x is a nonempty ,4-String} 

a V S, 7 g S77?.,4, 5^7 denotes the set defined by: 

{3 s gS A3 t eT 
b u = sur a #w = #5 + #r 
a min.Dom.u = min.Dom.s a max.Dom.s + 1 = min.Dom.t 



2.3.7 Observation : V.4g S<?r, V S,T,UeSTR.A, S^TeSTR.A A5 A (rC/) = (ST)~£/. 

In addition to the difference between sequences and strings, one should recognize that every 
finite sequence into a given set >1 has a unique ^-string containing it. This idea is embodied more 
precisely in the following observation, which justifies the notation that follows it. 

23.8 Observation : V 7 e Set, V S <= Fsq. T, 3 Str e STR. T B S e Str a V St e STR. 7, if S e Sr then Sr = 
2.3.9 Notation : V 7 6 Set, V 5 e 7, [5] denotes the unique member of STR. T such that S e [5]. 



2.4 IMPERATIVE PROGRAMMING LANGUAGE SYSTEMS 

In the definition of "imperative programming language system" given below: Sets Tk, Val, Rel, 
and VAL will represent tokens, values, relatior:, and Valu{*>}, respectively. A "program" is a member of 
Fsq.Tk with certain properties. A "state" is a member of Seq.VAL. FVaLP and ADR.P represent, 
respectively, memory locations in ROM where finitely many values are stored, and locations (out beyond 
ROM) allotted to program P for its use. A position in the program is an element of the program's 
domain, i.e., a subscript of the program. The domain of the "control function", Ctrl, is the Cartesian 
product Fsq.Tk x Seq.VAL x Z + . We use the projection functions St and Pos to pick out the state and 
position, respectively, from a given member of that domain. This motivates the following notation. 

2.4.1 Notation : V Tk, VAL e Set, V (5 \ s, k) e Fsq. Tk x SeqVAL x Z + , 



An "imperative programming language system" is a 14-tuple whose first three components, 
Tk (tokens), Vol (values), Rel (relations), and last component, Ctrl, were discussed in the preceding para- 
graph. The next four components are start, stop (two tokens), tru, and fals (two values).* The other six 
are functions: OprCorr, Com, Compat, Rcvr, v, and Loc. These building blocks of programming systems, 
outlined in the table below, involve (a) receivers (strings that can legitimately appear on the receiving 



St(S \ s, k) m s a Pos(S \ s, k) - k. 



* We refrain from appending "e" to these names to remind ourselves that these are just abstract 
values not known a priori. 



end of an assignment statement *), hence Rcvr ; (b) values, hence v ; (c) locations where values are 
stored, hence Loc; (d) rules of type compatibility, hence Compat\ (e) commands, hence, Com; and (f ) a 
mechanism for determining operational correctness, hence OprCorr, where "S is operationally correct in s n 
means (intuitively) that 5 causes no error during execution either of the compiler or of the program 
containing S - provided s is the "state of memory" when S is encountered in either execution (this does 
not prevent the execution of 5 from being nonterminating). 



FUNCTION TAKING 



OprCorr 
Com 
Rcvr 



Loc 



Compat 



(S y s) 
(S,s) 
(S,s) 
(S,s) 

(S y s) 

(52,52,55) 



TO 

tru 

fals 

tru 

fals 

tru 

fals 

some 

value 

CO 

some 
address 

CO 

tru 
fals 



INTUITION 

if 5 is operationally correct in state s 
otherwise 

if 5 is a command in state s 
otherwise 

if 5 is a receiver in state s 
otherwise 

if 5 is an "expression" (a K<?/-valued function of 

the receivers) in state s 

otherwise 

if 5 is a receiver in state s 
otherwise 

if 57, 52 are type-compatible "expressions" in 

state s 

otherwise 



The intuition behind the requirements labelled (1) - (8) in Definition 2.4.2 below is indicated as follows: 



1) oo is not a value, every value is a string of tokens, and Rel is a set of relations between values. 

2) Every value is operationally correct in every state and has itself as value in any state. 

3) Every command is operationally correct. 

4) A receiver in a given state is operationally correct and has its value stored in a location 
determined by that state. 

5) Every value is compatible with itself; any two type-compatible strings are operationally correct; 
and two strings compatible with some value are compatible with each other. 

6) Every value has a compatible receiver in some state and is stored in the location for thai 
receiver determined by that state. 

7) A program is a finite sequence of tokens, always starting and ending with start and stop, 
respectively; Ctrl stops at stop; its states have finitely many values stored in ROM; and Ctrl will 
not map any state or position in a segment out of its program. 

8) Everything in Rel has a Boolean representing it. 



A minimal example demonstrating the consistency of the following definition is in Appendix 1. 



' Choosing "receiver of values" as primitive avoids the issue of whether things like T 'A[2] n are 
"variables". 

8 

12 



2.4.2 Definition : (imperative programming language systems) 

i r 3 Tk, Val, VAL,Rel g Set A3 start, stop g Tk a 3 trujals g Val a VAL = Ka/uM 
a 3 OprCorr : SIR. Tfe x 5a?. —{trujals} 
a 3 Cow : STR. Tk x Seq. VAL —{trujals} 
a 3 Ccmpat : STR. Tk x STR. Tk x Seq. VAL —{trujals} 
A 3 Rcvr : 577?. Tk x Seq. VAL —{trujals} 
A3 v : 577?. 37c x Seq. VAL - VAL 
A3 hoc : STR. Tk x Seq. VAL — Z 0 M«>} 
A3 Ctrl : Fsq. Tk x Seq. VAL x Z + — jty. Tk x 5e<?. K4L x Z + 

bL = (7*:, Kj/, i?d, start, stap, trujals, OprCorr, Com, Compat, Rcvr, v, Loc, Ctrl ) 

1) a start * srcjp a a » £ J/ fl / c STR. Tk a Rel Q l Vtmrd 
A V (S,s) G 577?. 7fc x Sojr. ^4L, 

2) if 5 G Kfl/ then OprCorr(S,s) ^ tru a v(S,s) = 5 

3) a if Com(S y s) - tru then OprCorr(S, s) = rru 

4) a if i?cvr(5,s) = rrw then OprCorr(S,s) - tru a s^s.s) = e Pa/ 



L is an ^ 

imperative 

programming 

language 

system 



5) A V c G Ka/, V s G Seq.Val, Compat(c, c,s) - tru 

A V 5i,52 G 577?. 3Tfe 

if Compat(Sl,S2,s) = rrw then Compat{S2,Sl,s) - tru- OprCorr{Sl , s) = OprCorr(S2,s) 
A if Compat(Sl,c,s) - tru - Compat(S2,c,$) then Compat(Sl y S2 y s) = rru 

6) a V c G Fa/, 3 (S,s) G 577?. 7fc x 5e$. K4L 

9 i?cvr(5,s) - tru a Compat(S,c,s) ~ tru a v(S,s) = c - s^s,*) 

7) a if (P L is the set defined by 

fP G Fsq, Tk a min. Dom. P = 1 a P x = start A P #/ > = stop 

P g (P L 

[a 3 s g Se?. K4L 9 CJpK3arr([P] f s) = tru 
then 3 y4Z)/? : <P L - { Z m + | m G Z + } a 3 57: <P L - 2^^ a 3 FKa/ : <P L - 2 Val 
3VFg(P l ,Vsg S«f.K4L, Ctrl(P,s,#P) = (P,s,#P) 

A V c G FKfl/. P, 3 <2 G (L/hw. Dom. ADR. P-l 9 V 5 G 57. P, s fl = c 
A V (5 j, fc) G P*?. 7£ x 5*?. K4L x Z + , 

St. Ctrl(S \ s y k) G ST. P a Pos. Ctrl(S \ s, A:) G P 

8) a V R G /?<?/, V s G 5^.^4L, 

if i?CKs a { 5 | Rcvr(S,s) = tru} A 
EXPR.s = {S \ v(S,s) GVal A3 n gZ + B3f: (RCV. s) n — STR.Tk a 5 g Rng.f} 

then 3 b : (EXPR.s) 2 -EXPR.s 

B V £i,£2 g EXPR.s, if (v(£7,s), v(£2,s)) €■ R ) then v(b(El,E2), s) ^ tru 

a if (v(£i,j), v(£2,s)) « R ) then v(b(El,E2), s) = /afe 
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The following notation focuses attention on several sets that depend on a given state s : UNIT.s, 
RCV. s COM. s, EXPR. s, BE. s, and TypeEquiv. s. Their names are intended to suggest "units", 
"receivers" "commands", "expressions", "Boolean expressions", and "type equivalence", respectively. Intui- 
tively a unit is operationally correct in the state; receivers and expressions we have already characterized; 
a Boolean expression is one whose only values are tru and fals; and type equivalence is a relation on 
ilues It seems difficult to characterize what "command" should mean. A first thought might be a 
string S of tokens for which there is a state s such that the execution of S begun in state s would result 
in a change of state. However, that would exclude the empty command, as well as loops and condition- 
als whose bodies consist of the empty command. Thus, we only specify that there must be a way to 
determine whether a given string of tokens in a given state is a command or not. 

Also defined below is a very important function, PC P , which is called "program control in P . 
"St" and "Pos", defined earlier as projections from a triple Cartesian product, are here overloaded to 
designate projections from a double Cartesian product as well. 

2.4.3 Notation : IPLS denotes the class of all imperative programming language systems. 
Vic IPLS, V s e Seq. VAL, 

A if Tk = L z a Val = L 3 a tru - L 6 a OprCorr a L 8 a v = L u a hoc = L u a Ctrl ■ L M 

then 

<S L , ADR, ST, FVal, RCV. s and EXPR. s are defined in Definition 2.4.2 
a UNIT, s = {u e STR. Tk \ OprCorr(u,s) = tru} 
a COM. s = {Ce STR. Tk \ Com(C,s) = tru} 
a BE.s * {b e EXPR.s | v(b,s) e {tru, fals} } 
a TypeEquiv. s m {(u,w) e Val x Val \ Compat{u,w,s) = tru} 
a V P e <$ L , PC P denotes the function such that PC P :ST.Px l..#P -ST.Px l..#P 
a V (s,k) e ST. P x l..#P, PC P (*,/:) = Ctrl{P,s,k) 
a V (5, it) e ST.Px L.#P, a Sr(s,fc) - s a Pos(j,fc) = £ . 

2.4.4 Theorem : Every relationship has a Boolean expression for that relationship, and type equivalence 

is an equivalence relation. More precisely, let L e IPLS, P e <? L , Val = L 3 , tru ■ L 6 , 
ReRel* L 3 , and s e S7\P. 

(1) V £7, £2 e £XPi? . 5, if Compat(El,E2, s) = tru 

then 3 fo £ J5£. s9( v(fot,.y) = rru « (v(£7,5), v(£2, *)) e P ). 

(2) TypeEquiv. s is an equivalence relation. 

Proof: See Appendix 2. 

2.4.5 Definition : (types) 

{s e Se<?.K4L 
a T is an equivalence class determined by TypeEquiv. s 
10 
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2.5 PROGRAM EXECUTION AND PROGRAM CONSTRUCTS 

We now define an execution of a program segment as a sequence of pairs in the domain of the 
program-control function PC P , where P is the program in which the segment appears. Intuitively, execu- 
tion starts at the initial token of the segment and moves under program control either forever or until 
reaching either the last token of the program or the token just beyond end of the segment. 

2.5.1 Definition : (executions of segments) Let L g IPLS, P e <? L , and 5 g SEG.P. 

£ is an 1 fine Z 0 + u{co} a 3 s e ST.P 

execution** <=J B E: Z 0 " +1 — 57. P x l..#P a £ 0 = (s, mm. Dom. S ) a V i € Z 0 ", E M = PC P . £, 
of 5 j |a V k G Z + , ((Pos. Eie = #P G Dom. 5 or Pos. E k = max. Dom. 5+1) « = #£ ) 

£ is an execution of \ 

l<=> (£ is an execution of 5 a #£ g Z 2 + ) 
5 that terminates J 

2.5.2 Notation : V L e IPLS, V P g <?z, , V 5 g 5£G. P, 

£rec. P. 5 as { E | £ is an execution of 5} 
a EXEC. P *z uiExec. P.S \ Se SEG. P] 

a EX P s= {( (5,5), £ ) g (5£G.P x 57. P) x EXEC. P \ St.E 0 = J a £ G £xec.P. 5} 

2.5.3: Theorem : Given program P and state 5, there exists an execution of P beginning in s ; 

given segment 5 of P, if there exists an execution of 5 that begins in s> then that execution is 
unique, so relation EX P is actually a function. More precisely: 

Let L g IPLS, P g <P L , and 5 g 5£G. P. 

(1) V ^ g 5T.P, 3 £ g Exec.P.P B 5r.£ 0 = 5. 

(2) V £7, £2 g Ecec. P. 5, if Sr. £7 0 = St. E2 0 then £7 = £2. 

(3) £#, : Dom. EX P - EXEC. P . 

Proof: See Appendix 2. 

Note in the following definition that, even though we choose to name delimiters so as to suggest 
a while-loop, there is nothing inherent in the definition to distinguish the construct being defined from 
an if-then-endif construct. 
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2.5.4 Definition : (citadels) 

Let Le/PLS and Tk^L 2 . 

t W<= STR. Tk 



W 



is a \ 



citadel 
in L 



A 3 s e Seq. VAI, B 3 while, do, endwhile, sp, b,C e UNIT, s 
B # {while, do, endwhi!e,sp} = 4aV SeqTok G whileudo\jendwhileusp, #SeqTok 
aW= while~ sp~b~sp~do~sp~C~sp~ endwhile 
a V P G (P L , if WnSEG.P * 0 

then 3s e ST.Pb W,Ce COM.s a b <= BE.s 



2,5.5 Notation : VLg IPLS, 

if 7fc ^ L 2 

then Citad. L m { W e S77?. 77c | W is a citadel in L} 
aV^g Cited. L,V5G Se<?. VAL, V wAife, do, endwhile, sp, b,C <= UMIT. J, 
if ^ = while*sp~b~sp*do~sp~C~sp~ endwhile 

then Guard. ^ ■ & a Body. W ^ C. 

We now define a loop as a citadel with a certain kind of execution. That execution E 
determines a state sequence St and a position sequence Pos whose terms are the first and second 
elements of the sequence E of pairs. Intuitively: The term of St when Pos is at while is the same as the 
term of St when Pos is next at do (no side effects), and if the value of the guard in those states is false, 
then Pos moves to the first token beyond endwhile and execution terminates. Otherwise, Pos moves to 
the first token of the body.' St is then subject to change as Pos varies through the body to endwhile and 
back to while; and the process is repeated. If St has no term in which the value of the guard is false 
when Pos is at while, then the execution is infinite. 

In the following definition of a loop: The sequence jC> denotes that subsequence of the state 
sequence St consisting of those terms where Pos is at while; n denotes the number of iterations of the 
loop, and n e Z 0 + u{«}; Sum. k denotes the number of steps in the execution of the kth iteration of the 
loop- and sum. k denotes the sum of the steps in the individual parts, with 0(k) and y(k) denoting the 
number of steps in the execution of the guard V and >ody C \ respectively. Note that the length of each 
of the units while, sp, do, and endwhile is 1; so the number, sum.k, of steps in each iteration of the loop 
begun in state j<*> is the sum of 



1 (for sp), 

#EX P (b\sM), (for guard b) 

3 (for sp, do, and^p), 

#EXp(C\sto), (for body C) and 

3 (for sp, endwhile, and while). 
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2.5.6 Definition : (while-loop commands) Let L e JPLS, W e Chad. L, b * Guard. W, C = 5orfy. W, 
tru L 6 , and /a£y » L 7 . 

r VPe<P t , V W\b\C eSEG.P, 

ifW eWAfc' e&AC'eCA POS. ivMe ■ win. Dow. 

a POS. do b POS.whik+l+#b'+2 a POS.endwhUe ■ POS.do+l+#C"+2 
then V £ e £**!<:. P. W\ 

3 « e Z 0 + u{oo} 3 3 : Z 0 " - ST. P 3 - Sr. £ 0 A £ - EXtQV\^ 
a if « € Z 0 + then o e B£.$<"> A v(A,sW) = /a/* 
a if w > 0 

then vlfceZ,", be J3£. s« A^Ce COM. sf» 
a if j8. k ■ #EX(p\sP>) e Z + a 7. fc - #£*(C ', e Z + 

a 3um.k m s*- i j »o( 1+ (^;') +3+ (7-;)+ 3 ) 

then V fc e Zo"" 1 , v(M ( *>) =/niA£ SBltl = (sW, POS. while ) 

a E(Sum. k)+\ = (sM,POS.while+l) 
a v i e l..j8.*, = £W,5 (<:) )i 

A£ (Sto , t)+1+(/ ,. t)+ , - (s^ POS.do-1) 

A £ ( 5^ *) + 2 = (*<*>, POS. do ) 

A£ (am . t)+1+w ,.« + 3 = (sW,POS.do+l) 
a V i e I..7. fc, £ (Sum . t )+ 3+i = £AT P (C ', s™) ,• 
A£ ( 5 um .*) +1+( ^. t ) + 3 + ( 7 .t) + i = (i- (<:+1) . POS.endwhile-1) 
A £ (Sum . * )+1+(/J . t)+ 3 +(T t )+2 = (* (<:+1) > -POS. endwhUe ) 
a if « e Z + 
then £5^, = (*<">, POS. while ) 

A £(Wn) +1 = POS. 

A V i G l..j8.«, E l&ma)+Ui » £XX»' t 5W)i 
A^^,^.^, = POS. do-1) 

A £ ( 5„ m . „) + l + 0. n) + 2 = (S (n) , POS. ) 

A £(jiun. <i)+i+(^. n)+3 = ( j(n) > POS. etidwhile+l) 
A #£ = l+(Sum.n)+l + (j8.«)+3 



PFis a 



1 



loop 
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2.6 PROGRAM ASSERTIONS AND CONDITIONS 

We distinguish between "assertions" and "conditions". An assertion is a Boolean expression; a 
condition is a set of states. For every assertion Q , there is a condition consisting of those states s for 
which v(G,s) = tru. (The converse is not necessarily true.) While at first thought, restricting assertions 
to be Boolean expressions in the programming language might seem too restrictive, existential-quantifier 
and universal-quantifier assertions over very large, but finite, sets can be considered shorthand for multi- 
ple disjunctions and conjunctions, respectively. This tact seems more than adequate for making 
assertions about program code to be executed on finite machines. (All program states s might have 
s i = oo v i > m, for some m.) 

2.6.1 Definition : (conditions and assertions) Let L 6 IPLS and P e <? L ■ 

C is a condition of P «=> C c ST. P 
Q is an assertion about P in s <=* (s e ST. P a Q e BE. s) 

2.6.2 Notation : Vie IPLS, V P e <? L , V s e ST. P, 

ASSERT P . s == {Q g STR. Tk | Q is an assertion about P in 5} 
a V Q e STR.Tk, iitru=L c 

then COM), . Q ■ {s € 5L P | QeBE.s a v(Q, s) - tru}. 

2.6.3 Definition : (assertions true at a position) Let L e IPLS, P e , and frw ■ L 6 . 

Q is always true 



position k during ? 



execution £ of P 



Q g a k e £>cw. P a £ e £xec. P. P 

[ a V 5 g 57. P, V i g Dow. £, if £/ = (5, fc) then 5 e COND P .Q 



3.0 TRANSLATION 

It only remains to indicate how the appealing operational language in the statement and proof 
of Theorem 1.1.1 can be translated into set-theoretic terms. Phrases that translate directly from the 
definitions in Section 2 are omitted here, e.g., "execution E terminates" means M #£ g Z 2 + 

The context of the statement of Theorem 1.1.1 is that of "any execution or a loop in some 
program, so we can assume that we have a program P in which the loop W appears. Thus, "during 
any execution of W\ means "V E e Exec. P. W>\ where W e Wr$EG.P\ and we are considering an 
arbitrary execution £ of W\ The loop W oi the theorem fits the designation of a citadel in Section 2 
provided we make the following identifications. 

The loop W in the theorem The loop W in Section 2 
while while 
< guard > b 
do begin do 
<body> C 
end endwhile 

Note that, in order to make this identification, we have to consider the 8-character string 'do begin' as 
a string of length 1 (i.e., an equivalence class of singleton sequences having the form {(k, do begin)}, 
where k e U) « because do is defined in our development as a string of length 1, i.e., equivalence 
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class of sequences of tokens, each such sequence of tokens being a singleton set. Other spaces and 
carriage returns appearing in the loop of the theorem are identified with n sp* in our development. 
We assume that the W of our development fits the definition of a loop as given by Definition 2.5.6. 

3.1 THE STATEMENT OF THEOREM 1.1.1 

The meaning of the various phrases used in the statement of Theorem 1.1.1 are indicated as 

follows. 

• "an expression that is a function of the program variables" is a member of 

c\{EXPR.s^ | keDom.s^}. 

• n a statement about current values of the program variables" is a member of 

n{ASSERTp.sM | keDom.s^}. 

As indicated in these two interpretations, we consider to represent the sequence of states 
with domain Z 0 n given in the definition of a loop in Definition 2.5.6, and we let W\b\ and C 9 be 
members of SEG.P such that W eW,b'e b, and C e C. 

Note that E » EX P {W\s^). 

• "<guard> and <body> terminate" means 

"V k e Dom.s^\ #EX P (b\s™) y #EX P (C\sM) e Z 2 + \ 

• "no program variable changes value as a result of any evaluation of < guard >" means 

"V k e Dom.s^\ if EE = EX P (b\s&) then St. EE^^ EE = St.EE^^ £E \ 

• For each statement S, n S is true each time program control reaches <guard>" means 

"V k e Dom. 5<*>, S e ASSERT P . 5<*> a j<*> e COND P . 5". 

• n Expr is an expression that is a function of the program variables" means 

"Expr g n{ EXPR.ss \ 3 k e Dom.s^ 3 sP> = ss}\ 

• " 'Expr < c ' is true each time program control reaches < guard >" means 

n < c Val x Val ac 6 Val 
A V A: e Dom.s('\ 

v(Expr, $<*>) e Val a Compat(Expr, c, s&) = ^a e EXPR. 5« 
A '£x/>r < c' e ASSERT?. & A j« E COND P :Expr < c' ". 

• "whenever program control reaches line 2, if v 0 denotes the value of £rpr at that time, 
then the value of Expr is at least v 0 +l the next time program control reaches line 3" 
means 

"V t e Dom. £, 

if Pos. E t = min. Dom. C '-1 a v(Expr, St. E t ) = v 0 

Att — min{i e Dom. £ | i > t a Pos. E t = mar. Dom. C '+1} 
then v(£xpr,Sr.£„) > r 0 +l". 

3.2 THE PROOF OF THEOREM 1.1.1, PART (1) 

Some of the phrases used in the proof of Theorem 1.1.1 have already been translated above. 
Other phrases not yet translated that are used in the proof of Part (1) are indicated as follows. (The 
sequences /3, 7, and Sum used below are those with the same name designated in Definition 2.5.6 of a 
loop.) 
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"program control must reach line 3 subsequent to any time during E that it reaches 
line 2" means 

"V keDom.s('\ if (sum.k)+l+(p.k)+$ eDom.E 
then (sum.k)+l+(p.k)+3+(rf.k)+l <=Dom.E n 
"the value of Expr must increase by at least 1 each time <body> is executed" means 
"V k e Dom.s('\ if v(<guard>,s<*>) = tru 

then v(Expr f s^) > 1 + v(Expr,sMy 
"Expr has some value v 0 the first time program control reaches < guard > during £" 
means 

"3 v 0 € Kfl/ B Compat(Expr, v 0 = rrw a v(£xpr, s<°>) = v 0 ". 

• "<body> can only be executed finitely many times during E n means 

"3 m e Z 0 + 3 if (szim.m)+l+(£.m)-r3 e Dom.E 

then Pro. £(« m . m )+i+c/j. m)+3 * c 

• "the value of Expr [increases] beyond c during some execution of <body>" means 

"3 k 6 Dow $0) a v(£xpr,^ +1) ) > c" 
"<guard> can only be executed finitely many times [during £]" means 
"3 m eZ 0 + 3 (jum.m)+l+03./w)+4 & Dom.E 

3.3 THE PROOF OF THEOREM 1.1.1, PART (2) 

The meaning of the various phrases used in the proof of part (2) of Theorem 1.1.1, not 
already translated above, are indicated as follows. 

"there is a last time t that program control reaches guard [during £]" means 

"3 r e Dora, E B Pos. E, = rnin. b f a t = wor{/ e Dom. £ | Pos. £, = minDom. bT- 
"Inv is true at time r [which is the last time program control reaches <guard> 
during E] n and " 'not <guard>' is true at time r" and "Post is true at time r" means 
n v(im>,s< n >) = tru" and "v(< guard >,*<">) and n v(Post 9 s^) = rm". 

• "Port must be true when program control reaches line 4" means 

n v(Post 9 sM) = tru a Sr.E^zws = * (n)n - 

This completes the translation. 
4.0 SUMMARY 

The goal of this paper was to legitimize the use of the appealing operational language used in 
the statement and proof of Theorem 1.1.1 by defining "program control" and other operational concepts 
in terms of set theory. There were two key elements in the development of these definitions. One was 
a distinction that is not often made, and the other was a unifying use of a definition not often insisted 
upon. The distinction was between sequences and strings, with strings defined as equivalence classes of 
sequences. The unifying use was of the definition of a sequence as a function, a function as a relation, 
and a relation as a set. Since a sequence is a set, set operations can be performed on a sequence, e.g., 
taking its cardinality, taking its union with other sequences, using a sequence as the domain of a 
function, etc. 

Once the definition of an imperative programming language system was developed, all of the 
familiar terms used in discussing programs and programming could be defined as sets. In particular, all 
of the language used in Theorem 1.1.1 and its proof could be defined in set-theoretic terms. The two 
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most prominent such terms were "program control" and "execution of a program segment". Program 
control in a particular program turned out to be a function mapping each pair consisting of a position 
(in the program) and a state into a (possibly different) pair also consisting of a position and state. 
Execution of a segment of a program turned out to be a sequence of terms in the domain of program 
control for that program, with a terminating execution being such a sequence that is finite. 

Finally, each of the questionable words and phrases used in the statement and proof of 
fundamental Theorem 1.1.1 was translated into the precise set-theoretic terms defined in Section 2. 
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APPENDIX 1 



A MINIMAL EXAMPLE DEMONSTRATING THE CONSISTENCY OF THE DEFINITION OF 
IMPERATIVE PROGRAMMING LANGUAGE SYSTEMS 

We employ the standard notation of single quotes delimiting terms of sequences to represent 
strings, e.g., 'f? denotes ttie string of sequences each of which has length 1 and whose only term is 0, etc. 
We use tuple notation for defining sequences, indicating with an initial subscript what the minimum of 
the domain of the sequence is, e.g., we use "5 = l (a,b,cy as meaning "Si = a a S 2 = b a S 3 = c a #S = 
and we use "S = 0 (a> b, c)" as meaning n S 0 = a a S l = b a S 2 = c a #5 = 3". 

SYNOPSIS OF THE EXAMPLE 

Four tokens, built from sets of integers, form the set Tk of all tokens. Two of them are used to 
define start and stop. Another token, a, is used to define the string-of-tokens delimiter sp, which has 
length 1. The remaining token is used as the term for constant sequences of various lengths to form 
notable strings, two of which are tru and fals, which are also used as the only elements of Val. 

Two more notable strings, x and y, form a set Var, intended to suggest "variable". The only 
other notable strings are gets and Eq. String gets is used in the definition of two commands (each 
suggestive of an assignment statement), and "gm" is intended to suggest "gets the value of. String Eq is 
used as the middle unit in strings consisting of the concatenation of other units - strings intended to 
suggest a statement of a relation between the first and last unit. A single relation, ID (the identity 
function on Val), is defined and Rel is defined to be the singleton set containing ID. 

The only three commands in the system are the empty command, an assignment of y to x, and 
an assignment of x to y. The only three possible programs in the system use these commands, 
respectively, as their only components other than start and stop. All three programs have the same 
address space Z 2 + , all store value tru at address 0 and value fals at address 1, and all use location 2 to 
store values of receiver x and all use location 3 to store values of receiver y. The definitions of the 
seven required functions are designed to satisfy the eight requirements. The function Compat is defined 
in such a way that Val forms the only type in the system. 



DEFINITION OF THE EXAMPLE 

Define: « a 0 a start = Z + a stop - Z A a - {Z + } a p - {Z} a Tk ■ {start, stop, a, 0}. 



Note A3.1 : start,stop e Tk A start * stop a STR. Tk = { [t] | t e \j(Tk m - n ) \m,n e Z 0 + }. 

Define: sp = V a tru * '? a fals - tru^'P a x ^fals^ y p a gets sx A ^ Ay m gets~ y p a Eq my"? 
a Val * {trujalse} a VAI, Valui*} a Var ■ {x,y} a ID - {(tru, tru), (fals, fals)} a Rel * {ID}. 

Note A3.2 : mi./afr <z Val a tru * fals a «> $ Val a Val c S7K.7fc a VAL = Kfl/uW a ite/ c 2™ * ™ 
a Seq.VAL = { 5 | s : Z 0 + - {trujatsj*} ) 
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Define: s x (start 9 a 9 stop) a P^ 2) - x {stan, a.x.a.gets.a.y.ayStop) 

A = ! (start, a, gets, a, *, a, srop) 

a (P ■ {PC« f PP)} a Sr<? Mjs 5e$.K4L | s 0 = tru a *! fals) 
a V i G 1..3, ST.JPW - 57iP a ADR.F* m Z 2 + a FVaLP® m Val 

A £ « {5i ~sp~Eq~sp~S2 | Sl 9 52 € 57R. 7fc} a COM ■ {*/>, 'xagetsoy\ 'yagetsatx'} 

Define /, g: 57<P — by: V 5 - 0 (tru 9 fals 9 s 2i s 3 ,s A , ...) g 57.(P, /(j) - 0 (tru,fals 9 s 3 ,s 3 ,s 4 , 

g( s ) 3 o(truJals, s 2 ,s 2i s A , 

Define Ctrl: Fsq.Tk x 5e^.F/lL xZ + - Fa^7fc x Seq.VAL x Z + by: 

V (5\s,&) G Fsq.Tk x Seq.VAL x Z + , 

if 5 * <£ (P or s <£ ST.V then Ctrl(S \ 5, fc) ■ (5 \ 5, fc) 

Aif5'G(?ASG 5r.<P a 5 'jk = stop then 0/(5 \ 5, k) m (5 \ 5, k) 

AifS' e<S> as e Sr.ff A ( 5 \ G {start, a} 

or (5 * = P® a k e 1-2) 

or (5 ' g {P$\P&} a fc G 1..6u{8}) 

) 

then CW(5 \ 5, k) m (5 \ k+ 1) 
a if 5 ' g CP a ^ e 5r.<? aS'€ a Jfe = 7 

f(S\f(s) y S) if S'=P® 

then Ctrl(S\s 9 k) ^< 

|(5\g(*),8) if 5' = PW 

a otherwise, Crr/(5 5, A:) ■ (5 \ s, k). 



Define Com 9 Rcvr,OprCorr: STR.Tk x 5e<?.K4L — {tru, fals} and 
define Loc: STR.Tk x SeqVAL — Z 0 + u{«} and 
define v: STR.Tk x 5^.K4L — {mi,/<2&}u{<o} by: 



V (S 9 s)eSTR. Tk x Segr.VW, 

aw if 5 g COM 
/<a£y otherwise 



Com(S t s) m 



a i?cvr(S, s) 5* 



frru if 5 g For 
fals otherwise 
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)'tru if S e VahjVaruCOMui'start', 'stop'} uiPu E 
fals otherwise 
r 2 if S = x 



aLoc(S,s) M 3 ifS=y 
L «> otherwise. 

a if 5 € ValuVarvE or 5 € S7<P then v(S,s) ■ « 
a if S e Fa/uFanjE A s e S7(P then 

's if S e Fa/ 
s 2 if S = x 
v(S,s) 5 3 if S = y 

mi if 3 S1,S2 e SIRT/t 3 S = S! ~sp~Eq~sp~S2 A v(Sl,s) = v(S2,s) 
\fals if 3 S1,S2 e STR.Tk B S = SI ~sp~Eq~sp~S2 A v(S7,*) * v(52,5) 

Define Compat: STR.Tk x STR.Tk x Sea.P^ - {trujals} by: 

[rru if v(S7,i), v(S2, 5) e Val 

V (S2,S2,s) e STRJk x STATA: X Seq.VAL, Compat(Sl,S2,s) m 

fals otherwise. 

Define: L s (7*, Ka/, Rel, start, stop, trujals, OprCorr, Com, Compat, Rcvr, v, hoc, Ctrl ) 
a <P L » (P. 

Requirement (1) follows from Notes A3.1, A3.2. 
Requirement (2) follows from the definitions of OprCorr and v. 
Requirement (3) follows from the definitions of Com and OprCorr. 
Requirement (4) follows from the definitions of Rcvr, OprCorr, hoc, and v. 
Requirement (5) follows from the definitions of Compat and OprCorr. 

For requirement (6): Let c e Val and define S = x and 5 = 0 (tru,fals, c, c, c,...), i.e, s t = c V i e Z 2 ' 
The result then follows from the definitions of Rcvr, Compat, v, and .Loc. 

Requirement (7) follows from the definitions of functions ADR, ST, and FVal all with domain 
(P L = (P, and from the definition of the function Ctrl 

For requirement (8): Let R e Rel and s e S^.P^. Then R = ID = {(tru,tru), {fals, fals)}. 
Define function & as follows. Let E1,E2 e EXPR.s. Thzn v(El t s), v(El,s) e Val, and: 

3 m,k g Z + 3 3/1: (i?CK - S7tf.77c a 3 /2 : (tf CK - STRJk 
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b El € Rng.fl a E2 e Rng.f2 y 
so 3 rl : -7?CKj a 3 r2 : 1..A; -TJCF.j 
Bfl(rl ly ... y rl m ) = £7 A^i,,*) = £2. 
Thus, define az ^ m+k and define/: (RCV.sf -*STRJk by 

Vr: l..n-i?CKj, /fr r„) * fl(r ly ... y r m )~sp~Eq~sp~f2(r m + u ... y r n ) y 
and define fe(£7, £2) - /[rfi rl m , r2 a r2 k ). 
Then b(E! y E2) = fl(rh y ... y rl m )~Eq~f2(r2 ly ... y r2 k ) = El~sp~Eq~sp~E2 e £, by definition of £/ 
Since v(£i,s), v(£7,s) e Fa/, v(£7 ~sp~Eq~sp~E2 y s) e Fa/ by definition of v. Thus 
£2 ~sp~Eq~sp~E2 e EXPR.s, which shows that itog.r c £ATP7?. j, so b : (£ZP7?. s) z — EXPR.s. 

To prove the two desired implications, let £7, £2 e £AT7?. 5 and (v(£7, j), v(£2 ; 5)) € R = /D. Then 

v(fr(£7,£2), s) = v{El~sp~Eq~sp~E2 y s) by definition of 5; and £7 ~sp~Eq~sp~E2 e £ by 

definition of £, so 

= rrw by definition of v, 

which completes the proof of the first implication. The proof of the second implication is completely 
parallel, and it is omitted. 



• Note that string b(El y E2) = £7 ~sp~Eq~sp~E2 is well defined, even though fl y f2 y rl y r2 are 
not necessarily unique, i.e., there might exist fl\f2\ rl\ r? with the same properties WITHOUT /Z'= fl, 
fT = /2, etc. 

21 



APPENDIX 2 
PROOF OF THEOREMS 2.4.4 AND 2.5.3 



Proof of Theorem 2,4.4 : 

Proof of Pan (1) : Let s e STP, E1,E2 e EXPR.s, and Compat(El,E2,s) = tru. By property (8) of 
Definition 2.4.2, 

(*) 3 b: (EXPR. sf - EXPR. s 

b V EEUEE2 e EXPR. s, if (v(EEl t s) t v(EE2 y s)) e # ) then v(b(EEl,EE2), j) = rrw 

a if (v(££2,s), v(££2,s)) e ) then v<7>(££2,££2), s) - p& 
Define bx = b(El y E2). We first, establish the desired equivalence and then show thai ta g BE. s. 
If v(fer,s) = rru then v(fc(£2,£2), 5) = rru so "(v^Ei,*), v(£2,j)) e i? n cannot be true, because by line (*) 
that would imply v(b(£7,£2), s) -fab, so tru would equal /a/s, which would be a contradiction. This 
proves "=>" of the desired equivalence. 

If (v(£2,5), v(E2,s)) e R then, by line (*), v(fc(£l,£2), s) = rra, i.e., v(bx,s) = fry, which proves the 
other desired implication, and the desired equivalence is established. 

It only remains to show that bx e BE. s. Since bx = f?(£i, £2) e tog. b £ £XF«. 5, ta e £ATi?. s so wc 
need only show that v(bx,s) g {rru,/a£y}. But this follows from an argument parallel to the equivalence 
argument just given, because either *(v(El y s) y v(E2,s)) e R n is true or not, so there are only two cases 
to consider. In case this is true, v(bx,s) = tru, and in case it is false, v(bx,s) = fab. Since these are the 
only two possible cases, v(bx, s) e {trujals} in any case. Thus bx e BE. s, which completes the proof of 
Part (1). 

Proof of Pan (2) : Let s e Seq.VAL. By the first conjunct of requirement (5) of Definition 2.4.2, 

Vce Val y Compat(c,c y s) = tru, 
so (c,c) g TypeEquiv.s, which proves that TypeEquiv.s is reflexive. 

Let (c,d) G TypeEquiv.s. Then Compat(c,d,s) = rru, so by the second conjunct of requirement (5), 
Compat(d,c,s) = rru, i.e., (d,c) G TypeEquiv.s, 
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which proves that TypeEquiv. s is symmetric. 
Let (c,d), (d,e) e TypeEquiv. s. Then 

Compat(c,d y s) = tru = Compat(d y e y s) = Compat(e y d y s) 
by both the definition of TypeEquiv. s and the second conjunct of requirement (5). By the third 
conjunct, 

Compat(c y e y s) = rra, i.e., (c, e) g TypeEquiv. s y 
which proves that TypeEquiv. s is transitive, which completes the proof of Part (2). 

Proof of Theorem 2.53 : 

Proof of Part (IV . V s e Sr. P, define E inductively by defining 
E 0 = 

a V i g Z 0 + , if E, is defined and Pa?. £,• ^ #P 
then define £ lV1 = PC P . E,- . 
Then £ e Erec. P. P and Sr. £ 0 = s f which is what we wanted to prove. 

Proof of Part (2V Let El, E2 e £rcc. P. 5 and St. El 0 = Sr. £2 0 . The proof that El = £2 is by 
induction. Define £ by: 

f k G Z 0 + 

/: e # <W a if V i e 0.. k y i e (Dom. El)v(Dom. E2) 

\ then V i e Q..k, i e (Dom. El)n(Dom. E2) a Ei, « £2; 

0 e # because: 0 g Z 0 + and £J 0 - (». £7 0 , win, Dom. 5) = (St. E2 0 , mm. Dom. S) = £2 0 . 

Let k g K and we must prove that k+l g K. Then & g Z 0 + , which implies /:+1g Z + , so assume 

V i g 0../r+l, i g (Dom. El)U(Dom. E2) 
and we must prove that V i g 0.. k- , i e (Dom. El)n(Dom. E2) a El t = E2i . Thus we 

let i g 0../:+l 
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and we must show that / 6 (Dom. El)n(Dom. E2) a Eh = E2 : . If i e 0.. k then the desired result holds 
because k e K, so we need only consider the case where i = k+1. 

Case I. k+1 e Dom. El. Then k e Dom.£7 so, since k e K, k <= (Dom. El)n(Dom. E2) a El k = £2* , so 
(*) PC P . El k = pc p ■ E2 k because PC P is a function. 

If we can show that k+1 also belongs to Dom.E2, line (*) will convert to E1 M = E2 k+l . 
Suppose k+1 <£ Dom.E2. Then = #£2, so by definition of execution of 5, 
3 kk e Z 0 + 3 fc = sokkeK and £7^ = £2,* and 

Pos.E2 kk = #P orPoj.£2^ = mar. Dom. 5+1, i.e., 
Pos.Elu, = #? or Pos.Elkk = max.Dom.S+1, because E1& = £2^ -- 
and in either case kk+1 cannot be a member of Dom. El, i.e., £ cannot be a member of 
Dom. El. This contradicts the fact that k <= K (which implied that 
e (Dom.El)n(Dom.E2), as observed earlier). Thus our supposition is false, 
so k+1 e Dom. £2. Thus by (*), E1 M = £2, +1 , which completes the argument in this case that 
k+1 e K. 

Case II. k+1 e Dom.E2. The argument here that k+1 e A' is completely parallel to that of Case I, and 
it is omitted. 

Thus k+1 e K in both cases, which completes the proof, by the induction principle, that K = Z 0 + . Thus, 
by definition of K, El k = E2 k V k e (Dom. £7)u(Dom. £2), i.e., £7 = £2. 

Proof of Part (3V . We must prove that any "two" members of EX P that have the same first element must 
have the same second element as well, so let ( (S,s), El ), ( (5,5), £2 ) e EX P , and we wish to prove 
that El = £2. Then by definition of EX P , E1,E2 e Exec. P. S and St. El 0 - J = Sr. £2 0 , which 
satisfies the hypothesis of (2), so the conclusion holds, namely, El = E2. q.e.d. 
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